Cookie 与会话

复习

• HTTP 请求与响应：无状态的请求-响应模型
• HTTP 连接与版本演进：连接可以被复用
• 套接字：应用通信的接口

TL;DR

• HTTP 无状态，服务器默认记不住你是谁
• Cookie 是服务器让浏览器保存并回传的一小段数据
• 会话用 Cookie 里的标识，把多次请求联系起来
• Cookie 也带来隐私与安全上的考量

正文

　　HTTP 是无状态的：每个请求都独立，服务器不记得你上次来过。这在扩展性上很美，但在需要“记住用户”的场景里就很麻烦。比如你登录一次之后，总不能每点一个链接都重新登录吧？

　　解决这个问题的，就是 Cookie。

让浏览器替你记一张小纸条

　　Cookie 的思路很直接：既然服务器记不住，那就让浏览器帮忙记。

　　流程大致是：

1. 你登录成功，服务器在响应里加一句“请保存这段数据”（Set-Cookie）
2. 浏览器把这段数据存下来
3. 以后每次向同一网站发请求，浏览器自动把这段数据一起带上
4. 服务器一看这段数据，就知道“哦，是你”

　　于是，本无状态的 HTTP，就靠这张“小纸条”把多次请求串了起来。

会话：把小纸条变成身份

　　Cookie 里通常不会直接放你的账号密码，而是放一个意义不大的会话标识（比如一串随机 ID）。服务器在自己的内存或数据库里，用这个 ID 对应到“某某用户的登录状态”。

　　这样一来：

• Cookie 里只是一串无意义的编号
• 真正的用户信息和状态，保存在服务器一侧

　　这既避免了在客户端暴露敏感信息，也方便服务器统一管理登录、过期和注销。

便利背后的考量

　　Cookie 带来了便利，也带来了一些值得留意的点：

• 隐私：Cookie 会被浏览器回传到网站，可能被用于追踪用户行为
• 安全：Cookie 可能被窃取。因此敏感信息不宜直接放进 Cookie，并可通过 HttpOnly、Secure 等标记加以保护

　　这又是一个熟悉的主题：任何便利，都伴随着代价，关键看怎样把风险控制在可接受的范围。

思考题 1

　　无状态的 HTTP 怎样靠 Cookie 维持登录状态？

思考题 2

　　为什么敏感信息通常不直接存在 Cookie 里？

小结

知识点

• HTTP 无状态，需要额外机制维持状态
• Cookie 由服务器下发，浏览器保存并自动回传
• 会话用 Cookie 中的标识关联多次请求
• Cookie 带来隐私与安全上的考量

参考资料

1. Wikipedia(zh)：HTTP Cookie：服务器存储在客户端的数据片段
2. Wikipedia(zh)：会话 (计算机科学)：在多次交互之间维持的状态

思考题答案（仅供参考）

思考题 1

　　登录成功后，服务器通过响应让浏览器保存一个会话标识，之后浏览器的每次请求都自动带上它。服务器据此在自己的记录里找到对应的登录状态，从而“认出”你，弥补了 HTTP 无状态的不足。

思考题 2

　　Cookie 保存在客户端，且会在请求中来回传输，可能被窃取或篡改。若把密码等敏感信息直接放进去，一旦泄露后果严重。更稳妥的做法是只放一个无意义的会话标识，真正的信息保存在服务器一侧。

协议

　　本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

封面图

设计师 | 南国微雪